Bug description

Bard::preload() and Link::collections() both use the same Blink cache key routable-collection-handles-{site}, but they store different types in it:

• Bard.php:598 returns an Illuminate\Support\Collection (no ->all() at the end)
• Link.php:160 returns an array (has ->all())

Because Blink::once skips the closure on the second call, whichever fieldtype runs first wins. When a blueprint has both Bard and Link fields, Bard runs first and primes the cache with a Collection. Link then gets back a Collection instead of the array it expects, and passes it on to the nested entries fieldtype as the collections config.

Why it only shows up now

This collision has existed for a while, but it stayed hidden because the downstream code accepted both arrays and Collections. PR #14718 added a strict array type to Entries::getViewableCollections(), which now throws:

Statamic\Fieldtypes\Entries::getViewableCollections(): Argument #1 ($collections) must be of type array, Illuminate\Support\Collection given, called in .../Fieldtypes/Entries.php on line 214

How to reproduce

1. A blueprint with both a Bard field and a Link field (without an explicit collections: config on the Link)
2. A user role that cannot view at least one of the routable collections
3. Open an entry — the edit page fails with the TypeError above

The permission check matters because it triggers the new fallback branch in getColumnCollection() that passes the configured collections into getViewableCollections(array).

Changes in this PR

Add the missing ->all() in Bard::preload() so both fieldtypes write the same type into the shared cache.